Acceptance criteria pitfall

This latter use of acceptance criteria contains a danger. In practice, the following sometimes happens: after establishing and freezing the requirements, users discover that they have additional requirements. They then formulate these requirements as acceptance criteria. In this way, acceptance criteria form the ‘back door’ for taking in even more requirements. This is not a good method of operation. The only correct way is to submit a change proposal to a Change Control Board.

Example of other parties/individuals can supply the test process with relevant information:

• The overall test manager, at coordinating level, for obtaining insight into the test assignment and what is expected of the test or the test manager
• The (representatives of the) client, for obtaining insight into the business aims and the ‘culture’ as well as the aims and strategic importance of the system
• The project manager or quality management employee, for obtaining insight into the steps and components of the development process and the correlations, with special focus on the (expected) place of testing in this
• The domain experts from the user organisation, for obtaining insight into the (required) functionality of the system
• The designers, for obtaining insight into the system functionality to be developed
• System administrators, for obtaining insight into the (future) production environment of the information system
• Testers, for obtaining insight into the test approach and test maturity of the organisation
• The suppliers of the test basis, the test object and the infrastructure, for guaranteeing coordination at an early stage among the various stakeholders.

Examining the available documentation, example:

• Test documentation, such as the master test plan or a Generic Test Agreements document
• System documentation, such as stakeholder analyses, business or user requirements, or an information analysis, system requirements, functional and technical design
• Project documentation, such as the plan of approach for the system development process, organisational charts and responsibilities, the quality plan, review reports and a function-point analysis
• A description of the system development method, including the norms and standards
• A description of the test method applied, including the norms and standards
• Evaluations and points of learning from previous tests that may be relevant to the forthcoming test
• Contracts with suppliers